Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.
There are a wide range of testing tools available on the market, with prime examples being Rational (by IBM) and Mercury (by HP). In general terms, such tools allow users to test a software application, for example by executing test scripts in that application, and reviewing the results of that execution.
In known test tools, it is usual for each test script to have its own data set, which is used during the execution of that script (that is, the data is bound to the test script, typically through the coding of the script). For example, the data set may include aspects of data such as user names, passwords, product identifiers, and so on. Where there is a desire to run a similar script, but with different data, there is a need to create a new script specifically bound to that new data. For example, consider a test script configured to test “login” functionality. In a simple scenario, such a test script would be bound to a data set that describes all users. If there were a desire, on the other hand, to run that script in respect of only a subset of users (for example users with administrator rights), conventional methodologies would require a user to create a new script bound to a data set that describes that subset of users.
Such approaches inevitably lead to an unwieldy number of scripts, which can cause significant complications if there is a desire or need to make a minor change to a given functionality. For example, a minor change to the “login” functionality may result in a need to individually modify a large number of test scripts that invoke the “login” functionality.
Various attempts have been made to streamline the manner by which test tools operate. These include the likes of record replay automation, data driven architecture and keyword-based architecture. Each of these has significant short fallings in the context of the above comments. For example, in a data-driven architecture, reduced script numbers comes at the expense of a fast-growing amount of data sets, which becomes untenable, whilst script number containment in a keyword-based architecture results in a high degree of complexity, requiring a high level of skill of script maintenance or the like.
There is a need in the art for improved systems and methods for managing testing functionalities.